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5 RATE PROVI SIONING METHOD AND SYSTEM 

FOR AN INTERNET TELEPHONY CLEARINGHOUSE SYSTEM 

PRIORITY AND RELATED APPLICATIONS 

The present application claims priority to provisional patent application 
1 0 entitled, "Automated Support of Internet Telephony Clearinghouse Services," filed on 
Deceml^2271999^d~assignea"U:Sr ApplicatioiT"SOTarNumber60/l 71,375. The 
present application is also related to the following pending applications: U.S. 

Application Serial Number, , entitled, "System and Method for the 

Secure Enrollment of Devices with a Clearinghouse for Internet Telephony and 
15 Multimedia Communications," filed on December 22, 2000; U.S. Application Serial 

Number, , entitled, "Call Detail Record Method and System for 

Internet Telephony Clearinghouse System," filed on December 22, 2000; and U.S. 

Application Serial Number, , entitled, "User Interface for Internet 

—Telephony Clearinghouse System," filed on December-22-20b0; — 

—20 

_ TEC HNICAL FIELD 

The present invention generally relates to a rate input mechanism for voice 
over IP (Internet Protocol) communications. More particularly, the present invention 
relations to a rate provisioning method and system that assists in the tracking of voice 
25 over IP communications from a source gateway to a destination gateway. 

BACKGROUND OF INVENTION 

As an alternative to traditional switched circuit networics, telecommunications 
service providers have discovered that voice telephone calls may be routed over IP 

30 networks. Due to the fact that the Internet is not presently subject to the same 
international regulations as are traditional telephone networks, routing telephone calls 
over the Internet tends to be less expensive. Additionally, an IP routed voice 
telephone call requires much less bandwidth, and thus less cost, than a voice 
telephone call placed over a traditional telephone network. Further, IP technology 

35 advances are entered into the marketplace at a much faster rate than traditional 
telecom technology. Thus, in order to be competitive, telecommunications service 
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5 providers have begun to use IP routing as a way to offer customers access to the latest 
technological improvements. 

Presently, however, there is no centralized system for routing voice telephone 
calls over an IP network. Each operator of a gateway is responsible for determining 
the routes for its own outgoing calls. Typically, gateway operators rely on traditional 
10 IP routing algorithms, which are designed to handle routing of computer generated 
data packets. Traditional IP routing algorithms attempt to strike a balance between 
the concerns of minimum delay and maximum reliability. Thus, using traditional IP 
routing algorithms, a voice telephone call will be routed to any destination gateway 
that happens to satisfy a set of predetermined criteria such as shortest path and 
15 acceptable data loss parameters. 

The routing of voice telephone calls, however, involves a significant concern 
that is not shared by traditional IP routing algorithms. This additional concern is the 
monetary cost of routing a voice call to a particular destination gateway. As in 
traditional switched circuit networks, Internet telephony gateways impose fees for the 
20 service of terminating a voice call. Traditional IP routing algorithms are not able to 
detect and compare the varying price schedules that may be imposed by various 
Internet telephony gateways. Thus, source gateways are not able to discriminate 
between destination gateways based on monetary costs. 

One way a gateway operator can establish the cost for IP telephony services is 
25 by negotiating directly with other gateway operators a fee for terminating each other's 
calls. These gateway operators could identify each other and establish a bilateral 
agreement or a multilateral agreement. This approach closely resembles that of the 
international circuit switch telephony network, where providers in each country have 
established bilateral and multilateral agreements with each other. A significant hurdle 
30 for this routing implementation, however, is the large number of business 
relationships that must be negotiated and maintained. For example, should 1,000 
local operators decide to interconnect via bilateral agreements, 999,000 separate 
agreements would be necessary. Interconnection through a centralized system, 
however, would require only 1,000 separate business agreements, each with a separate 
35 operator. 
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Another disadvantage with a bilateral agreement model is that the gateway 
operators are not able to react quickly and intelligently to changing market forces 
because the bilateral agreements are generally long-term contracts. For example, 
when there is a sudden increase in demand for terminating calls to a particular area, 
the gateway operator in that area in unable to increase his terminating charges and 
take advantage-of a demand. -Additionally,- a bilateral-agreement -model or the 
multilateral agreement model are too cumbersome for the gateway operators to set 
call pricing based on selected call number ranges (any given subset of all possible 
telephone numbers). This is especially true if the total number of telephone numbers 
comprising a called-number range is too small. For example, it may be too 
cumbersome for the gateway operators to negotiate a specific call pricing plan for a 
specific customer with less than 1 00 numbers within their called-number range. 

Thus, there remains a need in the art for a method and system by which an 
originating gateway-o perator-may seLa.pri.ceJh.at.. it .is willing to pay to a terminating 
gateway operator for the service of terminating a IP telephony call. There's also a 
need for a method and system by which a terminating gateway operator may set a 
price that it is willing to accept in exchange for terminating an Internet Telephony 
call. There is a further need for a method and system configured for use by an IP 
routing engine for selecting routing options for a call based on matching the pricing 
criteria set by the originating and terminating gateway operators. 

There also remains a need in the art for a method and system by which a 
gateway operator may set or change call-pricing criteria on demand. There also 
remains a need in the art for a method and system by which a gateway operator may 
set or change call-pricing criteria associated with any subset of all possible telephone 
numbers. Additionally, there is a need in the art for a method and system which 
permits rapid implementation of changes to call-pricing criteria. Also, there is a need 
in the art for a method and system by which a gateway operator may set or change 
call-pricing criteria with minimal effort. There also is a need in the art for a method 
and system by which a gateway operator may set or change call pricing criteria by 
building upon previously-entered data. And lastly, there is a need in the art for a 
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5 method and system by whicl a gateway operator may set or change call pricing 
criteria that is simple for an ondnary computer user. 

^SUMMAR3LQRIN\^NXION^^ ■.— _ - 

The present invention provides a method and system for defining pricing 
10 information to be used by a call-routing engine for the purpose of determining a 
preferred route for routing telephony calls from, an originating gateway to a 
terminating gateway via an IP network. The Internet Telephony rate provisioning 
method and system of the present invention comprises a rate table with pre-assigned 
cells that may be used by both IP bandwidth providers (partners) and IP bandwidth 
15 customers (retail IP service providers). The rate table enables its users to enter 
information about their IP Telephony preferences, including pricing criteria. This 
information can be used by an IP call-routing engine to provide the originating 
^gateway operators, with a prioritized list of terminating gateways whose pricing 
^Pftlri^mateh- those^set-by^he^oi^mting — The~briginating 

20 customers enter information relating to call prices they are willing to pay for calls to 
-—particular ^called- ^numbers^at^'mi^lar times? ~'OrigiMtihg~cTistomers may often 
specify pricing criteria, which defines the circumstances in which call price is to be 
applied. Similarly, the terminating customers enter information about the call prices 
they charge for terminating calls to particular numbers at particular times. 
25 Terminating customers may also specify pricing criteria of their own. Call pricing 
information generally describes call prices as well as pricing criteria. 

Call pricing information is but one example of preferences and preference 
criteria that may be used for the purpose of determining call-routing priorities. Other 
preferences include, but are not limited to, delay tolerance and expected reliability. 
30 Any preferences and preference criteria entered via the rate table may be stored in a 
database that is accessible by a call-routing engine. When a customer initiates a call, 
the originating gateway operator requests that the service point operator provide it 
with routing information necessary to terminate the call. Using call pricing 
information (i.e., call prices and pricing criteria) and other preferences and preference 
35 criteria derived from a rate table, the call-routing engine associated with the service 
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5 point operator determines ti e routing information corresponding to the most 
appropriate terminating gateways. A prioritized list of terminating gateways is then 
provided to the originating gateway. When provided with this prioritized routing 
— - information, the-originating- gateway-may complete-the call-by choosing to terminate 
the call via any one of the appropriate terminating gateways. 
~40 ===^Users candefine4he prickg=Griteria by creating^ariom components which are 
— — then-assembled-to=define-what-rates are-preferred to-what-numbers at-what times, by 
both the originating and terminating customers. Basically, the users enter the pricing 
criteria into pre-assigned cells of the rate table. The pre-assigned cells in the rate 
table are locations within the rate table that relate to specific properties of the pricing 
15 criteria. For a user's convenience and to decrease improper placement of pricing 
criteria within the rate table, the user can be provided with a rate table template that is 
generated by the centralized or clearinghouse IP telephony system. 

A rate table can be created for each network __dg yjce that is part of the 
centralized or clearinghouse IP telephony system. For example, a rate table can be 
20 created for each gateway that handles IP telephony traffic over the clearinghouse 
system. Each rate table can include a customer identification number, an Internet 
protocol address for the network device, the type of service supported (i.e. voice or 
fax), the type of rate plan (originating or terminating), a currency identifier, a rate 
plan name, a UTC (coordinated universal time)--based date on which the rate plan 
25 begins, and the call pricing information. However, the present invention is not limited 
to the aforementioned information. Also, a rate table may be configured such that 
certain cells are required cells while other cells within the rate table are optional. 

The rate table of the present invention can be created with an ordinary 
spreadsheet computer program. After entering information into the pre-assigned cells 
30 of the rate table, a rate table can be saved in a file format that preserves the relative 
locations of the pre-assigned cells of the rate table. One such format is the CSV 
(comma separated values) format that can be used as a portable representation of the 
rate table. Such a portable representation of the rate table allows the rate table to be 
transferred to the centralized or clearinghouse system relatively easy. That is, after 
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5 completing entry of data into the, rate table, it can be saved in the CSV file format and 
then it can be transferred to the centralized system for validation and implementation. 
The centralized system can validate the transferred file containing the rate 

table-information-with~relative ease, since the CSV file format preserves the 

pre-assignment of cells within the rate table. In other words, upon receipt of the 
10 transferred file, the centralized system can. reconstruct the rate table because of the 
preservation of relative locations of the pre=assigned--cells^vithin4he file-format. The 
present invention is not limited to the CSV file format. Other file formats are not 
beyond the scope of the present invention. After validating and reconstructing the 
rate table contained within the transferred file, the centralized system can forward the 
15 rate information to one or more rate tracked network devices in the centralized system 
after a predefined period of time. 

With the present invention, call-pricing information for network devices can 

be-easily~~generated -and -modified with an-application program that permits the 

"manipulation ofTaBles such as ordinary spreadsheet application programs. In this 
20 way, once call-pricing information is entered for a network device, further updates to 
"the can^fianglnformatron can"b^easily made when only a few entries are changed. 
That is, when the rate plans for certain network devices only require slight 
modifications, old rate tables containing previous rate information can be simply 
modified or changed. Such slightly modified rate tables can then be transferred to the 
25 centralized system for implementation of the new rate changes for the network 
devices that are part of the centralized Internet Telephony system. 

That the invention improves over prior rate implementation devices for 
centralized or clearinghouse systems and accomplishes the advantages and goals 
described above will become apparent from the following detailed description of the 
30 exemplary embodiments in the appended drawings and claims. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 is a functional block diagram illustrating one or more users that can 
be part of the centralized or clearinghouse system of the present invention. 
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Figure 2 is a schematic representation of an exemplary operating environment 
for the present invention. 

Figure 3 provides an overview of the steps involved in an Internet telephone 
■~ialHfr~the : exem - ^---^j===r^^. rr— - 

Figure 4 is an exemplary display screen for an e-mail message according to 

the present-invention. ~ — — 

HFigure-S-is-ajrexempl^^^ file 

to a rate plan database of the present invention. 

Figure 6 is an exemplary rate table according to the present invention. 

Figure 7 is a logic flow diagram illustrating an exemplary embodiment of a 
method for creating and implementing an Internet Telephony rate plan for network 
devices of a centralized system. 

Figure 8 is a logic flow diagram illustrating an exemplary routine for 
transferring aTile^tp the centralis set forth in Figure 7. 

Figure 9 is a logic flow diagram illustrating an exemplary routine for receiving 
and validating data contained within a transferred file as set forth in Figure 7. 

Figure 10 is a-Iogic flow diagram illustrating another exemplary routine for 
transferring a file to the centralized system as set forth in Figure 7. 

Figure 1 1 illustrates another exemplary routine for receiving and validating 
data contained within a file as set forth in Figure 7. 

DETAILED DESCRIPTION OF THE EXEMPLARY EMBODIMENTS 

The present invention is referred to herein as a rate provisioning method and 
system. The present invention provides a system and method for implementing 
preferences, such as pricing criteria, which are to be used by a routing engine for 
routing telephony calls from an originating gateway to a terminating gateway via an 
IP network. A telephone call occurring via an IP network is often referred to as a 
"voice over IP" transaction. When a "voice over IP" transaction specifically involves 
the Internet, the description "Internet Telephony" may also be used to describe the 
transaction. An exemplary embodiment of the present invention will be described 
herein with respect to Internet Telephony. However, the principles of the rate 
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5 provisioning method and syrtem of the present invention apply to all IP routed 
transactions, including, but not limited to, "voice over IP" calls, "fax over IP " calls, 
and "video over IP" calls. 



Exemplary Operating Environm ent 
10 The following description of an exemplary ope rating environment and 

exemplary embodim en ts of th e present invention will refer to the drawin gs* in which 
like numerals indicate like parts throughout the several figures. Referring to Figure 1, 
this figure shows an overview of a method of determining a preferred route for 
completing an Internet Telephony call using the rate provisioning method system 35 
15 of the present invention. The originating gateway operators 20 represent the retail IP 
telephony service providers that set the price charged for a call placed by a telephone 
user. The originating IP network backbone operators 25 represent wholesale IP 
^bandwidth providers^who have- agreements with-the originating gateway-operators 20 
~—to-provide the=bandwidth in switching-necessary to route the telephone call. 
20 Similarly, the terminating gateway operators 15 represent the retail IP 

—Telephony^selrvice .providers that_set the price for terminating a call placed by a 
telephone user. The terminating IP network backbone operators 30 represent 
wholesale IP bandwidth providers who have agreements with the terminating gateway 
operators 15 to provide the bandwidth and switching necessary to terminate a 
25 telephone call. Those skilled in the art will recognize that a gateway operator has the 
capacity to serve as a gateway for both originating and terminating telephone calls. In 
fact, originating gateway operators 20 and terminating gateway operators 15 typically 
differ only in the role played in a particular call. Similarly, backbone operators can 
handle both originating and terminating telephone calls. The originating backbone 
30 operators 25 and terminating backbone operators 30 typically differ only in the role 
played in a particular call. Henceforth, both an originating IP backbone operator 25 
and an originating gateway operator 20 may collectively, or in the alternative, be 
referred to as originating customers 26. Similarly, a terminating IP backbone 
operator 30 and a terminating gateway operator 15 will collectively, or in the 
35 alternative, be referred to as terminating customers 31. 
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The rate provisioning method and system of a present invention allows an 
originating customer 26 to define preferences, such as rates that it is going to pay for 
calls placed to particular called numbers at particular times. Similarly, the rate 

---^rovisioning-method-and-system 35-allows a terminating customer 31 to define 
preferences, such as rates it will charge for terminating calls to particular called 

~_numbers^at--particular times. Information relating to rates that an originating 
customer-26-is-gGing4©^-)^m 

to rates that a terminating customer 36 will charge for terminating calls may be 
referred to as an "ask". Henceforth, a bid placed and an ask placed collectively or in 
the alternative is referred to as call preferences. 

Besides call preferences, the preferences defined by a customer may also 
relate, for example, to call delay and reliability. An exemplary embodiment of the 
rate provisioning method and system 35 may allow customers to define circumstances 
in whjch preferences-are to~be applied. For example, a customer may define 
preferences that relate to call preferences. A customer may also specify that the call 
preferences are to apply to calls made at certain times of the day, after a certain date, 
and/or to certain called telephone numbers. Such criteria-defining when preferences 
are to be applied are referred to herein as preference criteria. In the case where the 
preference in question is a call preference, such preference criteria may be referred to 
as pricing criteria. Henceforth, the detailed description refers to pricing criteria in 
describing exemplary embodiments of the present invention. However, it should be 
understood that pricing criteria is just one example of preference criteria that may be 
used in the accordance with the present invention to match originating customers with 
terminating customers. 

As illustrated in Figure 1, the exemplary rate provisioning method and 
system 35 may comprise a component of a system referred to herein as a centralized 
-system or clearinghouse 50. A clearinghouse 50 is configured to accept preferences 
and preference criteria, such as rate plans and schedules, from originating 
customers 26 and terminating customers 31, via the rate provisioning method and 
system 35. A clearinghouse 50 also implements functionality, which will be 
described below, for utilizing preference criteria in order to match an originating 
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5 customer's request to terminate a call with one or more terminating customers who 
are available to terminate the call and have pricing criteria and other preference 
criteria that match those defined by the originating customer 26. The matching 
described above may be performed in real time because both the originating 
customers 26 and terminating customers 31 may change their respective call prices 
10 and price criteria via the rate provisioning method and system 35 whenever they so 
desire. As shown, a clearinghouse 50 may further be configured to sendjq originating 
customers 26 a prioritized list of available terminating customers 31 . 

Clearinghouse Network Architecture 
15 Referring to FIG. 2, this figure shows an network architecture that serves as an 

exemplary operating environment for the routing engine 110 of the present invention. 
As indicated, the Internet 102 serves as the heart of the exemplary network 
architecture. Relying on the Internet 102 are five different systems that might 
™partieipate^-airlntern^ include: a calling 

20 party 104, a source gateway (also referred to as an originating gateway) 108, a service 
-~rpomt-li 2-inciudi (also referred to as a 

terminating gateway) 114 and a called party 118. As FIG 2 shows, a service point 
112 is coupled to a central database 120, which is also coupled to a billing and 
settlement system 124. While the service point 112 exists on the public Internet 102, 
25 the central database 120 and the billing and settlement system 124 remain in secured 
facilities. Private communication paths connect the remote equipment with the 
central database 120. 

The calling party 104 represents the user wishing to place a telephone call. 
Often, the calling party 104 will rely on a standard telephone handset to place the call. 
30 In fact, in many cases the calling party 104 may not be able to distinguish Internet 
telephony service from standard telephone service. The calling party 104 connects to 
a source gateway 108 through a public telephone network 105, such as a switched 
circuit network. In either case, the source gateway 108 serves as a bridge between 
ordinary telephones and the Internet 102 by converting telephone signals into data 
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5 packets (and vice versa) and transmitting the data packets over the Internet 102. A 
source gateway is operated by a source gateway operator 109. 

Similarly, the called party 118 is the user that receives a telephone call. A 
— xall^ telephone 
network 106, such as a switched circuit network. A destination gateway 114 is 

__10 eonneeted-to-the-Internet-W2 at-a-location-that-is-remote from the source gateway 108. 

— The-destination-gateway-l-l 4-is-operated-by-a-destination-gateway operator 11 5 and 
performs the same functions as the source gateway 108, i.e., bridging phone calls 
between the Internet 102 and a public telephone network 106, or an equivalent 
thereof. Destination gateways 114 differ from source gateways 108 only in the role 
15 played in a particular call. In particular, source gateways 108 act on behalf of the 
calling party 104, while destination gateways 114 act on behalf of the called party 
118. It is important to note that the same operator need not manage both the source 
. ..rgatew^T08"ahd the destination "gateway 1 T47"lh"faBtrthc exemplary routing engine 
110, is tailored for environments in which different owners operate the two types of 
20 gateways. 

- - - -Thefservice i5oirit T operat6rl25'may be a third party that is independent of the 
operators of the source gateway 108 or destination gateways 114. As indicated in 
FIG. 2, the service point operator 125 may maintain a private communications line 
with the service point 112, the billing and settlement system 124 and a related web- 

25 site 122. In the exemplary operating environment, all components maintained by the 
service point operator 125, i.e., the service point 112, the database 120, the billing and 
settlement system 124 and the web-site 122, are conveniently distributed between 
various geographic locations. Still, those skilled in art will appreciate that all 
components maintained by the service point operator 125 may be incorporated in a 

30 single system (service point 1 12) or any number of distributed systems. 

A service point 112 communicates with gateways over the Internet 1 02 and 
generally provides routing information to the source gateway 108. Given a 
destination phone number and other requirements (described in detail below), the 
service point 112, through the routing engine 110, identifies at least one appropriate 

35 destination gateway 1 14 to handle the telephone call. 
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5 The overall network rrchitecture Miat serves as an operating environment for 

the exemplary routing engine 110 may be thought of as comprising three different 
networks, each carrying the telephone conversation. The first network is the calling 
— partyls-telephone network 105-that -connects the-ealling-party-to-the-source- gateway 
108. The second network is the Internet 102, which connects the source gateway 108 
10 and the destination gateways 114 to each other. The third network is the called 

.„ party's telephon e network 106, which completes the conne ction from the destination 

gateway 114 to the called party 118. Although FIG. 2 (as well as this description in 
general) refers to the telephone connections as taking place through public telephone 
networks 105 and 106, Internet telephony service does not require such a connection. 
15 Some applications may use private networks, such as those provided by a private 
branch exchange; others may simply connect telephone handsets directly to the 
corresponding gateway. 

— — — Additionally, a -fourth network may be added -to the- general network 

architecture— Th^ou^ 126. A 

20 billing and settlement system 124 may be coupled to the service point 112 in order to 
Tireceive-informatio^ "aspects of the Internet telephony 

transactions. The billing and settlement system 124 may use a banking and funds 
transfer network 126 to execute the financial transactions coordinated by the service 
point 112. 

25 

Internet Telephony Example 

FIG. 3 provides an overview of an Internet telephony call in the exemplary 
operating environment. At step 201, an Internet telephony call is initiated when the 
calling party 1 04 dials a telephone number, which is transmitted to the source gateway 
30 108 for processing. The goal of the source gateway 108 is to locate a destination 
- gateway 114a-c that is able to. terminate the phone call. The source gateway 108 
relies on the service point 1 12 for routing assistance. 

At step 202, the source gateway 108 makes an authorization request to a 
service point 112. The authorization request indicates, among other things, the 
35 telephone number of the called party 118. At the service point 1 1 2, the routing engine 
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5 110 uses information in the authorization request, as well as preferences established 
for the source gateway's 108 cDst and quality requirements, to determine which of the 
destination gateways 114a-c aie eligible to complete the call. 

.. At -step.: 203, .the, service ..point 112 .then sends-an_authorizatjon -response 

message to the source gateway 108, which includes information relating to the 

J Q ideoth y_p f eligible destinatio n , gateways 114. In additi on, the aut horizatio n response 

. -^messag^cmtain&^^auihQri 

gateway 114. The authorization response ticket allows a destination gateway 114 to 
accept the call knowing that it has been authorized by the service point 112, and that 
the service point operator 125 will compensate the destination gateway operator 115 
15 for completing the call. 

Upon receipt of the authorization response message, the source gateway 108 
selects a destination gateway 1 14 from among the list provided by the service point 
112. At step 204 r the orig inating gateway 108-then-sends-a setup message to the 
selected destination gateway 114, as specified in International Telecommunications 
20 Union (ITU) H.323 and associated standards. Those skilled in the art will recognize 
that the Q.931 standard _may_be used to define the setup- message.: Jo complete the 
authorization, the setup message must include the authorization ticket for the 
destination gateway 114. Those skilled in the art will also recognize that the user-to- 
user information element of the Q.93 1 setup message may be used to convey the 
25 authorization ticket. 

Communication between the service point 112, the source gateway 108 and 
the destination gateways 114 does not require the use of standard protocols for any 
aspect of the Internet telephony calls themselves, including call setup. If the source 
gateway 108 and destination gateways 114 use a signaling protocol other than Q.931 
30 (which is specified by H.323 and H.225.0), then that protocol need only be capable of 
including the authorization -ticket in the initial setup message. The exemplary 
authorization ticket is approximately 2000 octets in length. Destination gateways 
114a-c may accept or reject Internet telephony calls based on the presence and 
contents of this authorization ticket. 
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5 After the Internet telephony call is completed, both the source gateway 108 

and the destination gateway 114 transmit a call detail report to the service point 112, 
as represented in steps 205 and 206. Call detail reports identify the call and record its 
^urationr 555 ^ af ^swedin^th^database ^20 and are accessed by the 

billing and settlement system 124 in order to reconcile financial obligations between 
10 the service point operator 125, source gateway operators 1 09 and destination gateway 

.-■ operators 115. -■_ , . . . , , ~ .. , . 

It should be noted that source gateway 108 and destination gateways 114 are 
free to establish connections without consulting a service point 112. For example, a 
group of gateways may all be owned by a common entity and may wish to exchange 
15 calls among themselves independent of a service point 112. In such an environment, 
the gateways are free to rely on a service point 112 only when no gateway in the 
group can serve a given phone number economically. Thus, the exemplary operating 
environment provides gateways with extremely flexible routing choices. 

AIsoTTfiose^KH^ will appreciate thaTTfie" exemplary operating 

20 environment may include multiple service points 112. Service points may be 
—distinguished by the specific" services they provide, as well as by their geographic 
location on the Internet 102. Geographic diversity optimizes performance by 
allowing a device to communicate with the closest service point 112. Proximity to a 
service point 112 minimizes delay in the communication exchange. Geographic 
25 diversity also increases the reliability of the operating environment. If one service 
point 112 becomes unavailable, devices using that service point 112 can automatically 
switch to a different service point (not shown) located elsewhere. 

Before a gateway is provided with access to a service point 112 the 
responsible gateway operator must enroll as a customer of the service point operator 
30 125. The customer enrollment process may take place through the web-site 122, via 
the Internet 102, using any well-known web browser. Gateway operators 109 & 115 
typically perform the enrollment from a desktop computer. Since the enrollment 
process typically requires disclosure of sensitive financial information (such as bank 
accounts or credit card numbers), the web connection between the gateway operators 
35 109 & 1 1 5 and the web-site 122 is secured by the secure sockets layer (SSL) protocol. 
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5 The web-site 122 uses SSL to authenticate itself to gateway operators 109 & 1 15 with 
digital certificates obtained from a trusted certificate authority. SSL also encrypts the 
information transferred between the gateway operators 109 & 115 and the web-site 

When the service point operator 125 accepts a gateway operator as a customer, 
_10_^t_proAades_the„custa^ password. The customer 

number-i^JJamming-coded-to-protect-against-comipti on.- -Once- assigned, -customers 

are allowed to change their password. The service point operator 125 may enforce 
certain restrictions on passwords to maximize security. Such restrictions may include, 
for example, a prohibition against words appearing in dictionaries, a requirement to 
15 use both upper and lower case characters and a requirement that customers change 
their password periodically. 

After enrollment is complete, gateway operators 109 and 115 are given 
authorization to access andmodify their accounts," via the Internet 1 02, through the 
web-site 122 which may also host the rate provisioning method and system 35. 
20 Enrolled customers may also be provided with access to timely and informative 
-reports on their-usage of a~ service-point- 112. Such reports may include up-to-the- 
minute billing information, potential fraud alerts, sophisticated usage statistics and 
detailed traffic profiles. Enrolled users may access these reports directly through the 
web-site 122, using a web browser, or they can download the information for 
25 importing into their own database or spreadsheet. Users may also elect to be notified 
via electronic mail, fax, or other means when certain events occur. Events eligible for 
this service include suspicious or fraudulent activity, minimum or maximum traffic 
levels at particular devices, and apparent failure of a device. 

An enrolled customer may activate individual devices to use the services 
30 provided by a service point 112. In the present discussion, the exemplary devices are 
Internet telephony gateways 108 and 114. However, those- skilled in the- art will 
appreciate that the exemplary operating environment may be configured to supports a 
wide variety of devices. As with operator enrollment, device activation takes place 
across the Internet 102 using well-known web browsers. Typically, device activation 



WO 01/47235 16 PCT/USOO/35069 

5 will take place at the device itself, while operator enrollment is performed from an 
operator's personal computer or workstation. 

The web-site 122 may be configured to support several different approaches 
~3or1ictiv^^ 122 
may be configured to support Windows, UNIX, and embedded operating 
- 10 — environments^-Jhose-skilled _in_the_art_wilLrecognize that .other, operating systems 

may-also be supported. 

With respect to the Windows operating environment, exemplary web-site 122 
may be designed to support the operating environments of Windows 95, Windows 98 
and Windows NT version 4.0 and later (collectively referred to as "Win32 
15 platforms"). For these operating environments, reliance may be placed heavily on 
Microsoft's Internet Explorer (version 3.02 and later) to generate key pairs and to 
request and install certificates. The Certificate Server component of Microsoft's 
"Int^etTnfo used to grant certificate requests. 

"As indicated in Figure 2, a clearinghouse 50 may comprise the components of 
20 a service point 112 (including a routing engine 110), a database 120, a website 122 

hosting the rate provisioning method and system 35 and a billing and settlement 

system 124. A service point operator 125 may be responsible for maintaining the 
clearinghouse 50. A service point operator 125 may be a third party that is 
independent of the originating gateway operator 20 or the terminating gateway 
25 operators 15. As illustrated in Figure 2, the service point operator 125 may maintain a 
private communications line with the service point 112, a billing and settlement 
system 124 and the website 122. In the exemplary operating environment, all 
components maintained by the service point operator 125 can be conveniently 
distributed between various geographic locations. Still, the skill of the art will 
30 appreciate that all components maintained by the service point operator 125 may be 
incorporated in a single system or any number of distributed systems. 

As mentioned above, a clearinghouse 50 may be configured to provide an 
originating gateway 108 with routing information relating to those terminating 
customers 31 who match the call prices and pricing criteria (and other preferences and 
35 preference criteria) set by the originating customers 26. A service point 112 
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5 communicates with gateways over the IP network 102 and generally provides routing 
information to an originating gateway 108. The service point 112, through the 
routing engine 110, identifies at least one appropriate terminating gateway 114 to 
handle a call. The service point 112 is coupled to the clearinghouse settlement 
platform that hosts the web-based user interface 122, the rate provisioning system 35, 
10 and the b illing s ystem. The function of the rate provisioning method and system 35 is 

to~pro\rideL_a_jai£cham 

customers 31 may enter their respective call prices and pricing criteria to be used by 
the routing engine 110 in order to provide routing information to the originating 
gateways based on the best matches for their preferences and preference criteria. 
5 Also mentioned above, call prices are but one example for preferences that 

may be defined by an originating gateway operator 20. Other preferences may relate, 
for example, to delay times and expected reliability. The routing engine 1 10 may be 
—configured to use-the-preferences set-by the originatinggateway-operator 20 as filters 
for eliminating potential terminating gateways and determining the most appropriate 
D terminating gateway to terminate a call. An originating gateway operator 20 may 
-specify none or any_combination of-preferences= as its -fi Iters. Also, an originating 
gateway operator 20 or a service point operator 125 may specify the maximum 
number of call routes that are to be returned by the routing engine 1 10 in response to a 
call authorization request. 

In an exemplary embodiment, a first preference referred to herein may be 
defined as "the maximum delay that an originating gateway operator 20 is willing to 
tolerate." The maximum delay is preferably the overall network delay, which is 
measured by the time taken for a signal to travel between the calling party 104 and the 
called party 118. The lower the network delay from when the calling party 104 
speaks to when the called party 118 hears the words, the higher the quality of the 
conversation. Those skilled in the art will appreciate that there are many other factors 
that determine delay or latency in a voice telephone call. Other examples of delay 
include: delay due to interlocking of digital conversation, buffering delays inside 
gateways, delays on public switch telephone networks (PSTN), etc. It is 
contemplated that such other sources of delay may be factored into the "maximum 
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5 delay preference." However, it is expected that network delay will be the most 
significant contributor to the overall quality of an Internet Telephony call. Thus, in 
the exemplary embodiment, other sources of delay can be ignored. 
" : ^^oth^-prefefence : ca^ "m^imum autonomous system :(AS):hop count 
that the originating gateway operator will tolerate." The IP network 102 may 

1 0 - --^n^rise^-collection^ traveling 
— from-an-originating gateway 108 to a terminating gateway 114 may traverse one or 
more autonomous systems. The fewer autonomous systems that a signal must 
traverse, the lower the network delay should be. While it is not necessarily true that a 
lower AS hop count will lead to lower delay, AS hop count does provide a good 

15 estimation of network delay. Furthermore, a lower AS hop count tends to suggest that 
there will be less signal loss (packet loss) when the voice signal reaches its 
destination. 

7J ^term ination of "AS hbpM"unt is instantaneous and may be derived from 

information relating the dynamic topology of the~JP network 102, which is dictated by 

20 congestion, etc., that is continuously gathered and stored in the database 120. To the 
contrary, network delay may only be determined by an actual measurement, as 
described above, which involves significantly more time than an AS hop count 
calculation. Therefore, an originating gateway operator 20 may elect to use the AS 
hop count as hop count preference, rather than the "maximum delay" preference. 

25 An additional preference may be defined as "autonomous system (AS) 

matching," which dictates that, whenever possible, a route should be chosen such that 
both the originating gateway and the terminating gateway 114 are the same AS. A 
determination of AS matching is similar to a termination of AS hop count. A 
determination of AS matching dictates that given the choice of an AS hop count of 0 

30 and any other AS hop count, the route having the AS hop count of 0 will be chosen. 
Similarly, "domain matching" and "platform matching" preferences may be defined, 
such that no terminating gateway 114 that operates in a specified domain or on a 
specified platform will be selected to terminate a call. 

Another preference can be "a maximum rate the originating gateway 

35 operator 20 is willing to pay for a call to a specific telephone number." All 
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5 terminating gateways 114 charging rates (the ask) that are greater than the bid are 
eliminated from the search for the optimal call route. A bid may be specified as a 
function of time of day, day of the week and/or destination. All preferences (bids and 
-^Ksfmay be expressedlnanytype of currency and any fraction^thereof.- ~ — - 

An originating gateway operator 20 may set as many or as few preferences as 

—10 it-wouId-like.~ It is_contemplated_that preferences other than the exemplary 

— preferenees-desGribed-herein-may-also-be-implemented.-Eorexample,- the.originating 
gateway operator may also set preferences defining that all terminating gateways 114 
that are not intraoperable with the originating gateway 108, or do not offer the 
requested type of service, i.e., voice or fax, are to be eliminated from consideration. 
15 Other preferences may include, but are not limited to the following: "historical 
availability," which eliminates from consideration all terminating gateways 114 that 
have historical availability less than the required availability specified by the 
" — originating gateway~operator 20;~ "preferred operator"- which - eliminates from 
consideration all terminating" gateways 114 that are rioT operated by a preferred 
20 operator specified by the originating gateway operator 20; "packet loss," which 
-eliminates from-consideration all terminating gateways 114 whose -historical packet 
loss is greater than the minimum specified by the originating gateway operator 20; 
"latency," which eliminates from consideration all terminating gateways 114 whose 
historical packet loss is greater than the maximum latency specified by the originating 
25 gaieway operator 20; "quality of service (QoS) score" which eliminates from 
consideration all terminating gateways 114 whose QoS is less than the minimum 
specified by the originating gateway operator 20; "RSVP preference," which 
eliminates from consideration all terminating gateways 114 that cannot support, or are 
on networks that do not support, bandwidth reservation; and "best worst case," which 
30 eliminates from consideration all terminating gateways 114 whose best worst case 
scenario for packet loss and latency exceeds the minimum best worst case scenario 
specified by the originating gateway operator 20. The best worst case is estimated by 
summing packet loss or latency between the originating gateway 20 and the reference 
point maintained by the service point operator 125 plus the latency and packet loss 
35 between the terminating gateway and a service point operator 125. For example, the 
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5 worst case for packet latency between the originating gateway 108 and the 
terminating gateway 114 and assumed to be equal to the packet latency between the 
originating gateway 108 and the service point operator 125 plus the terminating 
—gateway and-the servicepoint opefatdr il25.— -: — ^n-i - 

—10 .^ ^te^BroY^ , — . , „ 

screen 400 for generating an e-mail message 410 that can be transmitted from an 
originating customer 26 or a terminating customer 31 The e-mail message 410 can be 
generated by any application program such as Microsoft Outlook or other types of 

15 application programs. The e-mail message 410 is but one method of transferring a 
rate plan table to the centralized or clearinghouse system 50. In this exemplary 
embodiment, the e-mail message 410 has a "To" field in which the e-mail 
messa ge 41 0 i s_addressed: The e-mail message 41 0 further-includes a -subject" 
field 430 that has a predefined format. The predefined" format includes the word 

20 "provision" followed by the variables A, B, C, and D. The variable "A" can represent 
-the customer or subscriber identification numberl while the variable 4< B" can represent 
a gateway identification number. The variable 4t C" can represent the service type 
(such as voice or fax). The variable "D" can represent the traffic type (such as 
originating or terminating). The file attachment 440 should contain the rate trend 

25 table that has been saved as a CSV (comma separated values) file format that saves 
only the text and values as they are displayed in cells of the rate plan table. With this 
file format, the relative locations of pre-assigned cells within the rate plan table are 
preserved. For example, with the CSV file format, all rows and all characters in each 
cell of a table are saved. Columns with data are separated by columns, and each row 

30 of data ends in a carriage return. If a cell contains a comma, the cell contents are 
-enclosed in double quotation marks. The present invention is not limited to the CSV 
file format. Any file format can be utilized as long as the file format preserves the 
relative locations of the pre-assigned cells within the rate table. 

Figure 5 illustrates another exemplary display screen 500 that includes a user 

35 interface 510, which can be hosted by website 122 (See Fig. 2). The user interface 
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510 may have multiple frame;; where one frame displays a logo 520 of a user. Other 
frames can display a navigational tool 530 for navigating through the data supported 
by website 122. Another frame can include other tools or links such as the "upload 
—new-rate plan~link-540.— Upon-activating link 540rthe"user- can designate a location 
of the file containing the rate plan table that provides for the new or updated rate plan 
information. Similar Jo„the_embodiment_disc.ussed_with respect to Figure 4, the file 
-containing-the-rate-plan4abIe-for-the-embodimentillustrated in-Eigure-5-should.also be 
saved in a file format that preserves the relative locations of the preassigned cells 
within the rate table. Preferably, in the exemplary embodiment, such a file format is 
the CSV file format discussed above. 

Figure 6 illustrates an exemplary rate plan table 600 according to the present 
invention. This rate plan table 600 can be created by an application program 
supporting tables such as an ordinary spreadsheet program like Microsoft Excel. 
Eac h cellJrtO of the table is defined according to a row number and a column number. 
For example, cell 610A is defined by column B, row 1. Cell 61 OA can contain a 
customer identification number. Cell 61 0B can denote the gateway identification 
number from a device-information page of the user-interface hosted by. website 122. 
Further details of the remaining cells 61 0C through 610Q will be discussed and 
explained in further detail in Table 3 listed below. The present invention is not 
limited to the cell assignment illustrated in Figure 6. Different cell assignments, as 
well as increased or decreased number of cells with respect to those shown in 
Table 600 can be provided. In other words, the present invention is not limited to the 
number and type of cell assignments illustrated in Figure 6. 

Referring now to cell 61 0G, the cells that fall within the column defined by 
cell 61 0G refer to predefined geographical regions that can be used in setting up a 
single rate for a grouping of countries. For example, in the rate plan table, you can 
create one rate row for a region denoted as "AS" represents the geographic region of 
Africa. In the geographic region of Africa, a user may establish rate rows within the 
rate table for specific countries within the predefined country region, such as Egypt 
and Libya. In this example, all countries in the Africa region would inherit the rate 
for the "AS" region, except for the countries of Egypt and Libya (since these 
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5 countries would have their own separate rate rows within the rate plan table). Such a 
system prevents the user having to create multiple rows for multiple countries in the 
same zone with the same rate. 

r^-A-s^a^tfi^^ ls made to 

Table I. Table I demonstrates how separate rate rows can be created for individual 
JO .^ccumtri^jwi^ For example, 

aocordmg-to^bleJ^ (See the 

third row of Table I). All calls to 1404 (and not to 404851) will have a rate of 0.055 
units. (See row 2 of Table I). All calls to 1 (and not 404) will have a rate of 0.05 
units. (See the first row of Table I). All calls to country code 33 (France) will have a 
15 rate of 0.08 units. (See the fourth row of Table I). All calls to countries in the Europe 
country zone (except France) will have a rate of 0.09 units. (See the fourth row of 
Table I). All calls to all other destinations will have a rate of 0.15 units. (See the 
7sixthTow~of Table I): " 

20 Table I - Zone Rate Assignment System - Illustration 1 



Zone 


cc - 


-City tode/NPA- 
NXX 


Kate 




1 




.05 




1 


404 


.055 




] 


404K5I 


.0555 




33 




.08 


E\J 






.09 


OT 






.15 



Another example of assigning rates to calling zones and specific locations 
within a calling zone is illustrated in Table II. According to Table II, the first row, all 

25 calls to countries in Central/South America will have a rate of 0.08 units. Meanwhile, 
according to the second row of this table, all countries in Asia except to city code 1 in 
Turkey (country code 90 - see the fourth row of Table II) and to China (country code 
86 - see the third row of Table II) will haye a rate of 0.09 units. All calls to China 
(which has a country code of 86) will have the rate of 0.10 units. All calls to city 

30 code 1 in Turkey (which has a country code of 90) will have a rate of 0. 1 1 units, as set 
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forth in the fourth row of Table II. All calls to all other destinations will have a rate 
of 0. 1 2 units, as set forth in the fifth row of Table 2. 

z^z^rzzz— —Table II---Zo^ 2 ' - - 



Zone 




City Code/INFA- 
NXX 


Kate 


-SA 






.$,08 


AS 






$.oy 








$.10 




90 


1 


$.11 


OT 






112 



A calling zone may comprise one of the following regions: "AF", which 
denotes Africa; 4< EU'\ which denotes Europe; "AP", which denotes Australia/South 
Pacific ; "AS", which denotes Asia ; "CA ", whjchjdenotes Central andSouth America; 
_and "OT\ whichjdenotes jhe rest of the word. The country codes for the countries 
contained within the aforementioned zones are listed in Table VI. The country codes 
listed in Table VI may not include the latest and most accurate E.164 country codes. 
According to the International Telecommunications Standard ITU E.164, an 
international telephone number consists of a one to three-digit country code followed 
by no more than twelve additional digits. The first digit of the country code may be a 
digit from one to nine, and this is called a "zone." Therefore, all possible telephone 
numbers may be divided into called number ranges roughly by zone, or finally by 
country code, and with increasing specificity as the length of the number prefix is 
extended. By way of illustration, a called number prefix ("+1"), dialed from 
anywhere in the world, defines a called number range that includes telephone 
numbers in North and Central America (the plus sign is an international convention 
that represents whatever the user must do in preface to making an international call. 
In the United States, that usually means dialing the digits "011," but the exact 
procedure varies from country to country). Similarly, the called number prefix of 
"+1404" defines a called number range that includes numbers in Atlanta, Georgia. 
The exemplary rate plan table of the present invention is configured to allow a 
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number prefix having a maxinum of fifteen digits due to the fact that an international 
telephone number includes up to fifteen digits by convention. However, should there 
be a reason to extend a called number prefix past the current number of fifteen digits, 
the rate pfan^ 

Any countries not included in the zones set forth in Table VI are not 
xonsidered-pait-of-a-predefined-region r and4he -number -string -will have to be defined 
in-the-country- code-and-city-code/NPA-NXX-eolumns -of- the -rate plan table. 
However, the present invention is not limited to the E.164 country code standard. 
Any grouping of countries or cities or both can be adopted by the present invention. 

Referring now to Table III, as mentioned above, this table describes the cell 
assignments for the rate plan Table 600, as illustrated in Figure 6. As noted above, 
Table III and Table 600 of Figure 6 are illustrative exemplary embodiments of the 
present invention. In other words, the present invention is not limited to these cell 
assignments as can be appreciated to those of ordinary skill in the art. 



Table III - Cell Assignments 



Cell(s) 


Description/Action 


1A 


fcnter the label "Customer ID". 


IB 


Enter the subscriber ID trom the Ueneral lntormation page ot the User 
Interface. 


2A 


Enter the label "Device Name' . 


2B 


Enter the gateway ID from the Device lntonnation page ot the User interlace. 


3A 


Enter the label "Service Type". 


3B 


fcnter "V" lor voice or "b" tor lax. 


4A 


fcnter the label "Assignment 1 ype . 


4B 


Enter u O" for on ginatmg rate plan assignment or J tor terminating rate plan 
assignment. 


5A 


fcnter the label "Currency". 


5B 


Enter l i" (lor $US). 


6A 


fcnter the label"RP Name". 


6B 


fcnter an 8-character name lor this rate plan. 


8A 


Enter the label "BfcUllsT 


9A:9C 


This is the Called Number String composed of values in columns A through C. 

Zone (column A value) may be: 

# <blank> 

• AF = Africa Region (see list of countries in Table VI) 
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# EU = Europe R( gion (see list of countries in Table VI) 

# AP = Australia/South Pacific Region (see list of countries in Table VI) 

# AS = Asia Region (see list of countries in Table VI) 

# SA = Central and South America Region (see list of countries in Table VI) 

# OT =:Rest of-World (all files:must:include.at leastzoneTow with this value 
which is a default region) 

If one of the above values appears in Column A, there cannot be values in 
Columns B and C and vice versa. You may define rates by: 

# Regiorf(input Region code in column A; no values in columns B and C) 

# Country Code (input country code value in column B; no values in 
columns A and C) 

# Combination of Country Code and City Code (input country code value in 
column B and city code or NPA/NXX in column C; no value in column A) 

Columns B and C represent the Country Code and City Code respectively. 
The sum of digits in columns B and C may not exceed 7. 


yL) 


nnxer raie in juo per minuie. vajue may ue up 10 ** ucuujui piauc^. 


9E 


Enter "60". 




Enter "second". 


yu 


Enter the date when this rate becomes elective. Usually this will be the 
current ~dater~But~it is also possible toschedule future changes. That is, you 
may create several rows with the same number string but with different begin 




"dates and different rates as long as one of the begin dates is less than or equal 
to the date/time the file is submitted to the centralized system 50. 


9H 


Leave blank, (future use) 


91 


Leave blank, (tutureuse) 


rv I 

9J 


11 rates are lor terminating gateway, enter i n lermmaiion is ai loweu 10 uiis 
gateway for this row's Called Number String. Enter 4 'N" if termination is not 
allowed. 

If rates are for originating gateway, enter "Y" if origination is allowed from 
this gateway for this row's Called Number String. Enter M N M if origination is 
not allowed. 



5 

Referring now to Table IV, this table explains which particular cells within the 
rate plan table are required to have values. The table also provides an additional brief 
description of each cell's content. It is noted that some descriptions refer to a 
"phase". This "phase" is identifying how the present invention can be implemented in 
10 stages. During an initial phase, such as Phase I, the functionality or capability of the 
clearinghouse system 50 may be somewhat limited. After subsequent phases, such as 
Phase II, functionality of the clearinghouse system 50 will be enhanced to include 
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5 additional capabilities or options. Some descriptions of Table IV also refer to 
"UTC-based dates" UTC denotes coordinated universal time, which is the standard 
time common to every place in the world. In other words, UTC normally reflects the 

mean-solar-time-along-the prime-meridian-(O degrees-longitude).that runs through the 

Greenwich Observatory located outside of London, UK, where the current system 
JO originated. Coordinated universal time is ex pressed u sing a 24-hour clock and uses 
-the-Gregorian-calendar— It is-used-in~airplane~andship-navigation, where_it, is. also 
sometimes known as "Zulu time", Zulu being the military word for the letter "Z" and 
for the longitude 0. The full definition of coordinated universal time can be found in 
ITU-T Recommendation X.680 (7/94). 

15 

Table IV - Required and Optional Cells for Rate Plan Table 600 of Fig. 6 



Cell or 
Row or 
Column— 


Required 


Description 


bl 


Y 


User enters Customer ID 


B2 


Y 


User enters IP Address (1PJ>N 1 ) 


B3 


y 


In Phase 1, only "V" (voice) or "F" (tax) or 
supported. 


B4 


Y 


User enters "1 " tor terminating rate plan or "O 
for originating rate plan 


B5 


Y 


Currency ID 


B6 


Y 


User enters rate plan name (up to 8 alpha- 
numeric). 


Column 
A(A9) 


N il Column 
B has a 
value, Y if 
Column B 
does not 
have a value 


Zone may be: 
AF = Africa 
EU = Europe 

AP = Australia/South Pacific 
AS = Asia 

SA = Central and South America 

OT = Rest of World (all files must include at 

least one row with this value) 

If one of the above values appears in Column A, 
there cannot be values in Columns B and C and 
vice versa. 


Column 
B (B9) 


N il Column 
A has a 
value, Y if 
Column A | 


Note that "1 is the country code tor all North j 
American locations. All valid country codes 
(outside North America) are listed in Section 6 of 
this document. 
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does not 
have a value 




C(C9) 


N 


This i<; the citv code or NPA-NXX. 1 his value 

1 Ilia ID Ulv LJl Y vvliv Ul 1 j * *~* .* * ** »j * *** 

may be up to 6 digits. 


( ^olumn 

VV J UilllJ 

D(D9) 


See Section 
5, item 5 


1 i^er enters rate ner minute (UD to 4 decimal 
places). 


E(E9) 


See Section 
5, item 5 


In nhase I onlv "60" is SUDDOlted. 


Column 
F(F9) 


See Section 
5, item 5 - 


In phase 1, only "second" is supported. . 


Column 
G(G9) 


Y 


User enters the UTObased date on which this 
rate begins; format mm/dd/yy 


Column 
H(H9) 


IN 


(Applicable to Origination Kate flans only; see 
cell B4) 

In Phase I, this field will be left blank. 
In Phase 11, user enters Maximum Delay in 
milliseconds. This is an optional field. User 
may leave blank or enter any of the following 
values to be determined. 


— Column - 
KI9) 


— See Section 
„ _5,jtem_5_ 

-• ■ _-_ 


(Applicable to Origination Kate Flans only; see 
. celI.B_4) . __. . 

in rnase l, — is.suppon.eu. _ 

In Phase II, user may enter one of the following 

Routing Priorities: 

"LC (Least Cost) 

"LD" (Least Delay) 

"SA" (Same Autonomous System) 


Column 
J(J9) 


Y 


User enters "Y" to allow origination trom or 
termination to this device; otherwise, "N" 



5 

Referring now to Table V, this table provides an explanation of various cells 



contained within the rows of Table 600 of Figure 6. The information contained 
within Table V assumes that the rate plan data contain within Table 600 arrived at the 
service point 125 on July 16, 1999 at 3:00 a.m. UTC. 

10 

Table V - Explanation of Rate Plan Data in Table 600 of Fig. 6 



Row 


Explanation 


9 


# This device will be a candidate to terminate calls to "1 " (but not those 
matching 1770452, 1770 or 1404) from 7/16/99 03:00:00 UTC through 
7/31/99 23:59:59 UTC @ .04/min. 
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10 


9 This device will he a candidate to terminate calls to "1" (but not those 
matehinp 1 7704 *i > 1 770 nr 1 404"l from R/l /99 00-00*00 or later (S> 

.045/min. 


i 1 


THic Hoi rioo A\;i11 Via o r'inHiHotA tn fprmin^tp rallc \(\ "1404" frnifl 7/1 fVQQ 

0 i nib uevicc win dc a cjnaiaaic 10 icmiinaic caiib iu ihaj*t uum // 
03:00:00l:JTGroH?.ter@-04?./min: — 


1? 


*I hie Hf»vipf» will Hp si ranHirlntp tn tprminsitp pall^ tn **1 770" fexcludinf? 

1770452) from 7/16/99 03:00:00 UTC or later @ .043/min. 


_13 


_ # This-device-wilLbe-axandidate-to-terminate calls to "177045" from 

7/1 f>/QQ 0^-00*00 T TTP nr latpr ^ fl^S/mm 
// i\jiyy uil or idler (uj .ujj/iiiiii. 


14 


* This device will be a candidate to terminate all calls to Europe (CC's = 3 

nr 4^ frnm 7/1 fi/QQ OVOO-nO TTTP nr later /2) 077/min 

Ul *t J IIUJJI // lU/r^y UJ.IA/.UVJ Ulv UI laid \U£ .\J / //llllll. 


15 


s This device will be a candidate to terminate all calls to Africa (CC's = 2) 
except Morocco (CC 212) from 7/1 6/99 03:00:00 UTC or later @ 
.0912/min. 


16 


# This device will be a candidate to terminate all calls to Morocco (CC = 
9191 frnm 7/16/QQ 0^-00-00 TTTP nr later (n) 14S/min 


17 


• This device will NOT be a candidate to terminate calls to "541 1 " from 
7/16/99 03:00:00 UTC through 8/14/99 23:59:59 UTC since "Allow" = 
"N". 


1ft 


— TVnc Hpvirp will Hp n rsinHiHatp In fprminatp paIIq tn "S41 1 " frnm 8/1 S/Q0 

O 1 alio UCVJL/C Will UC a IsdJlUlUcLlC IU LCI IHJIlolv uollo IU J*tl 1 O/ 

00:00:00 UTC or later @ .065/min. 


19 


# In the context of this rate plan, "OT" includes all calls to "5" (except 

terminate calls matching those number prefixes from 7/1 6/99 03:00:00 
UTC or later @ .070/min. 



5 

Referring now to Table VI, as mentioned above, this table lists the individual 
countries that form each of the five calling zones that include "AF" for Africa, "EU" 
for Europe, "AP" for Australia/South Pacific, "AS" for Asia, and "SA" for Central 
and South America. Also listed adjacent to each country contained within a zone is 

10 each country's country code according to the ITU E.164 standard. It is noted that 
these lists may not include the latest and most accurate E.164 country codes. The 
most current listing of the country codes can usually be found at the following 
website: www.itu.ch. According to the present invention, any countries not included 
in Table VI are not considered to be part of a predefined region, and therefore, the 

15 number string for a particular country not considered part of a predefined region may 
have to be defined in the country code and city code/NTA-NXX columns of the rate 
plan table. It is noted that the columns of Table VI are in a "newspaper" format. Data 
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in one column on a page con inues to an adjacent column (in a left to right, top to 
bottom fashion) when the da a of Table VI is displayed on more than one page. 
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laoie vj - Predefined Regions and Countries in each Kcgiun 



Africa (AF) 
20 - Egypt 

212 - Morocco 

213 - Algeria ^ 
216 - Tunisia 
218 - Libya 

220 - Gambia 

221 - S eneg al 

222 - Mauritania 

223 Mali— Republic 

224 - Guinea (PRP) 

225 - Ivory Coast 

226 ~ Burkina Faso 

227 - Niger 

228 - Togo 

229 - Benin 

230 - Mauritius 

231 - Liberia 

232 - Sierra Leone 

233 - Ghana 

234 - Nigeria 
235 Chad 

236 - Central 
African' Republic 

237 - Cameroon 

238 - Cape Verde 
Islands 

239 - Sao Tome and 
Principe 

240 - Equatorial 
Guinea 

241 - Gabon 

242 - Congo 

243 - Zaire 

244 - Angola 

245 - Guinea-Bissau 

246 - Diego Garcia 

247 - Ascension 
Island 

248 - Seychelles 
Islands 

249 - Sudan 

250 - Rwanda 

251 - Ethiopia 

252 - Somalia 

253 - Djibouti 

254 - Kenya 

255 - Tanzania 

256 - Uganda 

257 - Burundi 



258 - Mozambique 

260 - Zambia 

261 - Madagascar 

262 - Reunion 
rIslandr-_ ~ _ _ 

263 - Zimbabwe 

264 - Namibia 

265 - Malawi 
266~=~LesotKo 

2 67_ r_Bo_tswana 

268 - Swaziland 

269 - 

Comoros /Mayo t te 
Island 

27 - South Africa 

290 - St. Helena 

291 - Eritrea 

298 - Faeroe 
Islands 

299 - Greenland 

—E urope— (Egt= 

30 - Greece 

31 - Netherlands 

32 - Belgium 
~~ 3 3 - France. 

34 - Spain 

350 - Gibraltar 

351 - Portugal 

352 - Luxembourg 

353 - Ireland 

354 - Iceland 

355 - Albania 

356 - Malta 

357 - Cyprus 

358 - Finland 

359 - Bulgaria 
36 - Hungary 

370 - Lithuania 

371 - Latvia 

372 - Estonia 

373 - Moldova 

374 - Armenia 

375 - Belarus 

376 - 

Andorra/Vatican 
City 

377 - Monaco 

378 - San Marino 



380 - Ukraine 

381 - 

Yugoslavia/ Serbia 

385 - Croatia 

386 - Slovenia 

387 - Bosnia & 
Herzogovina 
389 - Macedonia 
39 - Italy 

40 - Romania 

41 - 

Switzerland/Liechte 
nstein 

420 - Czech 
Republic 

421 - Slovak 
Republic 

43 ■ - Austria 

44 - United 
Kingdom 

45 - Denmark 

46 - Swed en 

47 - Norway 

48 - Poland 

49 - Germany 

Central /South 
America (SA) 

500 - Falkland 
Islands 

501 - Belize 

502 - Gua temal a 

503 - El Salvador 

504 - Honduras 

505 - Nicaragua 

506 - Costa Rica 

507 - Panama 

508 - St. Pierre & 
Miquelon 

509 - Haiti 

51 - Peru 

52 - Mexico 

53 - Cuba 

54 - Argentina 

55 - Brazil 

56 - 

Chile/Easter_Island 

57 - Colombia 

58 - Venezuela 
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590 - Guadeloupe 

591 - Bolivia 

592 - Guyana 

593 - Ecuador 

594 - French Guiana 

595 - Paraguay 

596 - 

Martinique/French_A 
ntilles 

597 - Suriname 

598 - Uruguay 

599 - Netherlands 
Antilles 



Australia/South 

Pacific (AP) 

60 - Malaysia 

61 - 

Australia/Cocos- 
Keeling Islands 

62 - Indonesia 

63 - Philippines 

64 - New 

Zeal and/ Cha tham 
Island 

65 - Singapore 

66 - Thailand 

670 - Mariana 
Islands 

671 - Guam 

672 - Christmas & 
Norfolk 

Islands /Antarctica 

673 - Brunei 

674 - Nauru 

675 - Papua New 
Guinea 

676 - Tonga Islands 

677 - Solomon 
Islands 

678 - Vanuatu 

679 - Fiji Islands 

680 - Palau 

681 - Wallis and 
Futuna Islands 

682 - Cook Islands 

683 - Niue 

684 - American 
Samoa 

685 * Western Samoa 



686 - Kiribati 

687 - New Caledonia 

688 - Tuvalu 

689 - French 
Polynesia 

690 - Tokelau 

691 - Micronesia 

692 - Marshall 
Islands 



Asia 


(AS) 


7 




Russia/ CIS 


81 




Jar} All 


82 




South Korea 


84 




Vietnam 


850 




North Korea 


852 




Hong Kong 


853 




Macau 


655 




Cambodia 


856 




Laos 


86 




China (PRC) 


880 




Bangladesh 


886 




Taiwan 


90 




Turkey 


91 




India 


92 




Pakistan 


93 




Afghanistan 


94 




Sri Lanka 


95 




Burma 


(Myanmar) 


960 




Maldives 


961 




Lebanon 


962 




Jordan 


963 




Syria 


964 




Iraq 


965 




Kuwait 


966 




Saudi Arabia 


967 




Yemen 


968 




Oman 


971 




United Arab 


Emirates 


972 




Israel 


973 




Bahrain 


974 




Qatar 


975 




Bhutan 


976 




Mongolia 


977 




Nepal 


98 




Iran 


993 




Turkmenistan 


994 




Azerbaijan 


995 




Georgia 
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5 Referring now to Figure 7, this figure illustrates an overview of the 

computer-implemented process for generating a rate plan and transferring it to a 
clearinghouse system 50. Step 710 is the first step in the computer-implemented 
process of the internet telephony rate provisioning method and system 35, where rates 
for a single network device are identified according to calling zones or exceptions to 
10 the calling zones or both. Inan exemplary embodiment, the network devices can be 
gateways 108 or 114 that are part of the clearinghouse system 50. However, the 
present invention is not limited to these types of network devices and can include 
other similar network devices. Other network devices include, but are not limited to, 
routers, gatekeepers, and other similar network devices. 
15 Next, in step 715, network device information and rate information are entered 

into pre-assigned cells of a rate table such as the rate table 600 as illustrated in 
Figure 6. Network device information can include a customer identification number, 
- " ■ a device name (the Internet protocol: addressrof a device), a service type (voice or 

fax), a type of plan (originating or terminating) the currency identification number, 

20- and_a_ rat.e__.plan name. Basically, the rate information can correspond to 
cells 610A-610F, as illustrated in Figure 6. A single rate table 600 is created for each 
device, each service type of the device, and each role of device. That is for a single 
device, several rate tables 600 may be needed. Exemplary scenarios that require 
separate rate tables 600 include, but are not limited to the following: a gateway that 
25 supports fax service in an originating role; a gateway that supports fax service in a 
terminating role; a gateway that supports voice service in an originating role; and a 
gateway that supports voice service in a terminating role. Thus, for each identified 
scenario, a separate rate table can be employed. 

With the inventive system, the user could be provided with a template for an 
30 ordinary spreadsheet program such as Microsoft Excel for the purposes of entering the 
rate plan information. In an exemplary embodiment, the user would then save the 
Excel file as a CSV file prior to submitting it to the clearinghouse system 50. Users, 
therefore, have the flexibility to bypass the spreadsheet program and create a CSV file 
directly. Rate Table 600 can be designed for any increments of time. In one 
35 exemplary embodiment, each rate table can denote a weekly schedule that includes a 
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single 24X7 time period. Add tionally, rates indicated in the rate table 600 can be in 
increments of rates per minute. However, other time increments are not beyond the 
scope of the present invention Bach rate table is associated with a single currency 
tool7~fii "one exemplary environment, "it is assumed there is only one clearinghouse 
account established for each user, and each clearinghouse account is associated with 
only one currency. 

~ In one exemplaiyTmbodimeht, an account can be established for each 
currency so that a user can select, within a single rate table, the currency associated 
with each rate listed in the table. 

Each rate table 600 and its corresponding CSV file will be validated to 
ensure that the currency designated in the rate plan table 600 is equal to the currency 
associated with the user's clearinghouse account maintained in database 120 of the 
clearinghouse system 50. 

. Next, in step 720, the-rate table-600 is stored in a file format that preserves the 
relative locations of the pre-assigned cells of the rate table 600. In one exemplary 
embodiment, the CSV file format is used to preserve the relative locations of the 
pre-assigned cells. However, as noted above, the present invention is not limited to 
the CSV file format. Other formats can be utilized as long as the relative locations of 
the pre-assigned cells can be reconstructed by the clearinghouse system 50 after it is 
transferred to the clearinghouse. 

After step 720, in routine 725, the file containing the rate table is transferred to 
the centralized or clearinghouse system 50. Further details of routine 725 will be 
discussed below with respect to Figures 8 and 10. In one exemplary embodiment, the 
rate table preserved in each file will typically include a complete set of rate plan data 
that is equivalent to an instance or version of a rate plan. That is, the rate table will 
typically include sufficient information to rate all traffic to all configured number 
prefixes from the date on which the file is sent to the clearinghouse system 50. For 
each number string of the rate plan data, there typically must be at least one row with 
a "begin date" equal to or less than the current processing date. A file may include 
rates that become effective in the past and continue to be in effect. Therefore, a user 
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5 is not requested to restate "begin dates" each time a file is sent, and the file may 
represent a cumulative view of all previous versions of the file. 

After routine 725, in routine 730, the rate plan data contained within a 
transferred file is received and validated. Further details of routine 730 will be 
discussed below with respect to Figures 9 and 11. All times relating to rate plan data 
10 " as well as processing of the plan"data~by the~clearinghouse~system"50* is typically 
UTC-based. For example, upload or transferred date/time means upload or 
transferred date/time UTC. Also, the system time of the clearinghouse system is 
converted to system time UTC whenever the file is stored or used in a calculation. 
Rate plan effective dates and assignment effective dates displayed in the user interface 
15 are also UTC-based. 

Also in step 730, once the set of new rate plan data for the device is stored in 
the Billing Engine database, all previous rate plan data sets (previous assignment 
_ef£ectiveidates)i^ be 
-flagged-as "superseded", and these can be maintained in the Billing Engine database 
20 „ for a set period of time. Qnl^the current version of the rate plan data is used to build 
views that are transmitted periodically to the database of the Service Points 112 where 
real-time routing decisions are made . When the Routing Engine 110 at the Service 
Point 112 makes a routing decision, it records the rate plan identification number in a 
call detail record. The call detail records are periodically transmitted from the Service 
25 Point 1 10 to the Billing Engine database. The rate plan identification number written 
to the call detail record is subsequently used by the Billing Engine to identify the rate 
to be used to rate the call for billing purposes.Next, in decision step 735, it is 
determined whether a successful validation has occurred. If the inquiry to decision 
step 735 is negative, then the "no" match is followed back to step 710. If the inquiry 
30 to decision step 735 is positive, then the "yes" match is followed to step 740. In 
step 740, the rate information from the rate table is stored in the Billing Engine 
database from which it is transmitted to the Service Point(s) 112 after a predefined 
period of time. Typically, the clearinghouse system 50 will disseminate rate plan data 
to service point 125 within 48 hours of receipt of the rate plan file. The new rate plan 
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data set will have an assignment effective date equal to the date/time when the date is 

written to the Billing Engine database 122 plus 24 hours. 

Thereafter, it will be possible for users to view rate plan data (retrieved from 

the Billing Engine database) through a user interface supported by web site 122. 

Users will be able to view the most current set of rate plan data only for their devices. 
"The user interface selects from the Billing Engine database and displays rate plan data 

with the most cun^nfuploaddate/time. 

After step 740, in decision step 745, it is determined whether a request to view 

rate information has been received. If the inquiry to decision step 745 is negative, 

then the "no" branch is followed. If the inquiry to decision step 745 is positive, then 

the "yes" branch is followed to step 750, in which the rate plan infoiroation is 

displayed on website 122 through a user interface. 

Referring now to Figure 8, this figure illustrates a computer-implemented 
process-for the-transfer--fite-rout^ step in 

- routine 725A, in which-an-e-mail message as set forth in.Figure 4 is created. Next, in 
step 81 5A, portions of the device information is identified in a predefined format in 
the subject line 430 of the e-mail message 410. In step820A, the file created in 
step 720 is attached to the e-mail message 410. Next, in step825A, the e-mail 
message 410 is sent to the centralized or clearinghouse system 50. In step 830A, the 
process returns to routine ?30 of Figure 7. The present invention is not limited to the 
aforementioned transfer methods. Other transfer methods include, but are not limited 
to, fax, forwarding files on disk, and other like methods. 

Referring now to Figure 9, this figure illustrates a computer-implemented 
process for the receive and validate data routine 730 of Figure 7. Step 91 OA is the 
first step in routine 730A, in which receipt of the file transferred in step 725 to the 
centralized or clearinghouse system 50 is logged. In step 91 5A, the CSV file is stored 
in a rate plan database 120. Next, in step 920A, the status of the file is logged. In this 
step, once it becomes possible for a user to upload the rate plan file via an upload link 
on the user interface, a real-time review is performed and the user can be advised 
immediately if the rate plan file is accepted for further processing. In step 925 A, data 
contained within the CSV file is validated. The validation process can include, but is 
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5 not limited to, comparing da a within the reconstructed rate plan table with a cell 
assignment template, in comparing device information against device information 
contained within the database 120. Other exemplary validation functions include, but 
are not limited to the following: (Examples of preliminary validation, before storing 
the file in the website exemplary embodiment of Figures 10 and 11, include items 1 
"TO — 0iroup"6^1ow: — Secondary validatiorTThat can tak^-plac^uringnP rocessin g 
"following uploading include items 7 and 8 below. For the E-mail exemplary 
embodiment of Figures 9 and 10, both preliminary and secondary validation will take 
place at the time the file is processed following receipt of the file via e-mail.) 
1 . Validate field values according to Tables III and Table IV. 
15 2. Validate that there are no duplicate rows for the combination of Zone, CC, 

City/NPA-NXX and Begin Date. 

3. Validate that there is at least one row with "Zone" = "OT" 
==zr4^Validate^^ 

~\saX least one row with a— Begin Date- equal to-or- less than- the-current-processing 
20. „date_(sysdate).„ 

5. Validates that required fields are populated. 

- If "Allow" = "Y" and "Role" = "O", there must be a valid value in each field 
except "Maximum Delay (ms)". 

If "Allow" = "Y" and "Role" = "T", there must be a valid value in each field 
25 except "Maximum Delay (ms)" and "Routing Priority". 

If "Allow" = "N" and "Role" = "O" or "T\ there must be a valid value in each 
field except "Rate", "Unit of Measure", "Increment", "Maximum Delay (ms)" and 
"Routing Priority". 

6. Validate that the first row of rates is preceded by a row with "BEGIN" in 
30 the "Zone" field, and the last row of rates is followed by a row with "END" in the 

"Zone" field. 

7. Validate the combination of "Customer ID" and "Device Name". 

8. Validate combination of "Customer ID" and "Device Name" with "Role". 

9. If there is a value in Column A of the rate plan table, there cannot be values 
35 in Columns B and C and vice versa. 
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10. Validate "Currency " with customer's clearing account currency or user's 
currency in a user table 

The present invention is not limited to the aforementioned validation 
functions or techniques. The present invention could include any number of 
validation functions or techniques or both. In step 930A, the result of the validation 
^^-925A~ is^ogged7~In~otte^ can 
display the status of the file from receipt through secondary validation and storage of 
rate plan data in the Billing Engine database, at which point this data is viewable by 
the user via the user interface. In step935A, the process returns to step 35 of 
Figure 7. 

Referring now to Figure 10, this figure illustrates another 
computer-implemented process for the transfer of file routine 725 of Figure 7. 
Step 1010 is the first step of routine 725B, in which the user interface of the 
-eentralized-or-elearinghous on-website-122.-Jn-step-l 01 5, an 

-upload link- such-as-link 540, as illustrated in_Figure 5, As activated- Next, in 
step 1020, the location of the CSV file created in step 720 is identified. In step 1025, 
the uploading process for the CSV file is initiated. In step 1030, the process returns to 
routine 730 of Figure 7. 

Referring now to Figure 11, this figure also illustrates another computer- 
implemented process for the receive and validate routine 730 of Figure 7. Step 1110 
is the first step of routine 730B in which a first validation process is initiated while the 
file data is being received during the transfer process. This first validation process 
can be referred to as a preliminary validation before the rate plan data is written or 
stored in the database 120. Next, in step 1115, the CSV file transferred in step 725 is 
stored in the rate plan database 120. In step 1120, a second validation process is 
initiated. In decision step 1125, it is determined whether a successful validation 
process has occurred. If the inquiry to decision step 1125 is negative, then the "No" 
branch is followed to step 1140. If the inquiry to decision step 1125 is positive, then 
the "Yes" branch is followed to step 1130 in which the file data is forwarded to tables 
in the Billing Engine database from which the web site 122 retrieves rate plan data as 
illustrated in Figure 2. 
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5 In step 1135, a message is sent to the user acknowledging the successful 

validation of the reconstructed rate plan table. After step 1135, the process proceeds 
to step 1145 in which the tracking information pertaining to the upload is logged. 
That is, parameters such as the upload time is recorded in UTC based time. In step 
1 140, a message is sent to the user and to the centralized for clearinghouse system 50 

error details that identify any specific problems with the "CSV file that was transferred. 
In step 1150, the process returns to decision step 735 of Figure 7. 

It should be understood that the foregoing relates only to illustrative 
embodiments of the present invention, and numerous changes may be made therein 
15 without departing from the spirit and scope of the invention as defined by the 
following claims. 
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5 What is claimed is: 

1 . A method for creating and implementing a rate plan for a network device 
within an Internet telephony clearinghouse system, comprising the steps of: 
identifying calling rates for a single network device; 
10 placing network device information and the calling rates into 

preassigned cells of a rate table; 

storing the table in a file format that preserves relative locations of the 
preassigned cells in the rate table; and 

transferring the file to a the Internet telephony clearinghouse system. 

15 

2. The method of claim 1, wherein the step of identifying calling rates fiirther 
comprises identifying calling rates according to at least one of predefined calling 
^~zones and country-city code combinations 

20 3. The method of claim 2, wherein the step of identifying calling rates further 

comprises identifying calling rates according exceptions to the calling zones. 

4. The method of claim 1, wherein network device information comprises at 
least one of a customer identification number, an Internet Protocol address for the 

25 network device, a type of service supported by the network device, a type of traffic 
supported by the network device, and a rate plan name. 

5. The method of claim 1, wherein the file format comprises a comma 
separated values (CSV) format. 

30 

6. The method of claim 1, wherein the step of transferring the file, further 
comprises transferring the file via an E-mail message. 
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5 7. The method of chiim 1, wherein the step of transferring the file, further 

comprises transferring the fi*e via a file transfer protocol and real-time validation 
supported by a website. 

8. A method for creating and implementing a rate plan for a network device 

TO withinairlnternet telephony-rfearinghouse system; comprising the-s 

j^r ce jyj n g- a fjj e in a predefinedTonhartKat contains relative locations 
of preassigned cells in a rate table; 

validating the rate plan data; storing the rate plan data in a database; 

and 

15 periodically transmitting selected rate plan data to a service point 

network devices where routing decisions are made. 

9. The method of clai m 8 , wherein the file format comprises a comma 
separated values (CSV) format. 

20 

10. The method of claim 8, wherein the step of receiving the file, further 
comprises receiving the file via an E-mail message. 

11. The method of claim 8, wherein the step of transferring the file, further 
25 comprises receiving the file via a file transfer protocol supported by a website. 

12. The method of claim 8, wherein the step of validating the rate plan data 
further comprises comparing the rate plan data to a rate table template listing 
acceptable ranges of values for particular cells. 
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